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Abstract 


Good requirements are the first step for good communications, and good communications are central to 
insure an understanding between the customer and contractor. Failure to generate good requirements is 
unfortunately commonplace and repeated. Waivers to requirements are discussed from a risk based point 
of view. The assumption that every requirement will eventually be waived is used to establish a critical 
review of a draft safety requirement. Validation methods of requirements are addressed. Value added that 
safety requirements contribute to the Project is estimated to further our critical review of draft 
requirements. 


Introduction 


The first and fundamental issue is to recognize the difference between a standard and a requirement. 
Standards typically provide a general set of useful design attributes, or operational criteria. A standard is a 
document listing either technical engineering design practices in a specific field. Tailoring the standard and 
levying it in a contract represents the standard evolving into a requirement. Requirements fall into 2 
categories: those with a technical basis and those with no technical basis. 

No requirement is perfect. The assumption that Program forefathers created perfect & timeless 
requirements is not valid. A requirement can not be written to account for all special cases. In addition, 
environmental conditions and assumptions on which the requirement is based constantly change. 

Requirements 

A checklist of useful requirement’s attributes and things to avoid in generating a good requirement may 
help: 

• Do the requirements contain only verifiable and measurable essentials? Nice to have ideas have 
no place in a concise set of requirements. 

• When developing a requirement by tailoring an existing standard, keep in mind that the only 
portion of the standard that needs tailoring are things impacting schedule and funding. 

• The requirements must be sufficiently detailed to permit the bidder to estimate schedule and labor. 
Suggestion - When the first draft Request for Proposal (RFP) is complete, 2 or more safety 
professionals should bid each requirement based on the RFP verbiage and compare their bids. If 
the bids disagree beyond a pre-established range, then the requirement needs rework. 

• Proposal language must be clear. When drafting the RFP, avoid pronouns and do not be 
concerned with any awkwardness when restating the noun. 

A checklist related of the requirements generation process includes: 

• Identify assumptions, constraints, and limitations. 

• Separate background information and contract objectives from technical requirements. 

• Explain interrelationships between tasks and deliverables. 



• Deliverable reports are normally tied to milestones such as the Preliminary Design Review, 
Critical Design Review, etc. Regarding the scheduling of deliverable reports, exercise caution, 
especially when the design is only for a simple piece of hardware. For example, a report may be 
required to be delivered 30 to 60 days before a design review for seemingly good rational allowing 
the Government or customer time to review the report and cycle it back to the contractor with 
adequate time to incorporate comments. The contractor typically has an internal review process 
for the draft report of 30 days before its release to the Government. The contractor’s safety 
engineer needs 15 days to complete the draft report before entering the contractor’s internal review 
and approval process. The caution is that the report can be scheduled for delivery in the presence 
of process restrictions that back up the time so that the contractor’s safety engineer must complete 
his draft before the designer commences with the design. 

Requirement Assessment Strateev 

Examples of processes for assessment of requirements are shown in the tables in this section. Table 1 is 
used by NASA’s Constellation Program CxP-01010 - Crew Exploration Vehicle (CEV) to Lunar Surface 
Access Module (LSAM) Interface Requirements Document. The author’s requirement’s assessment 
evaluation process is shown in Table 2. The checklist provides useful information for requirements 
evaluation and expands some of the headings in the tables: 

• Is the requirement technically based? If a waiver is requested, are there engineering equations or 
engineering tables to support waiver rationale? 

• Is the requirement risk based? Assumptions: (1) Both personnel and flight hardware exposed to 
the hazard risk. (2) Residual risk normally exists in presence of full compliance to the 
requirement. The risk is represented by a probability that the risk will materialize into a problem 
and contribute to a mishap. 

A change in risk is estimated in the presence of a waiver of a requirement. This risk change 
should be checked against the noted residual risk of compliance to the requirement. Often there is 
no change for hardware risk that can be noted within the constraints of the risk management 
matrix. An example is the Space Shuttle Challenger Solid Rocket Booster seal bum mishap. Both 
Marshall Space Flight Center engineers and Thikol engineers conducted test to better understand 
risk associated with seal damage with a result which would have shown no change in the risk 
matrix in the opinion of the author. 

• Does the requirement get the attention of the contractor? Working tasks (requirement) interest the 
contractor or supplier. The task must be biddable in a source board process with an estimated 
dollar value. Contractors focus on requirements that impact schedule or budget. Examples of 
attention getting requirements may be a deliverable report or a design feature. When there is a 
risk, then a contractor should be paid for that risk. 

• Is the requirement verifiable? Methods of validation of each requirement must be considered. 
Analysis, similarity, test, review of documentation, and inspection are common methods of 
requirements verification. Unverifiable requirements serve little value. 

• What is the estimated value added of the requirement as applied to improving hardware 
robustness? 

Requirements Change Evaluation Process used for NASA’s Constellation Program is provided below: 
Description: 

• State purpose of item and what’s being requested of the board (approval to proceed, 
status only? etc.) including a brief description of the change request /action item. 

* What Program requirements are being developed, revised, and/or waived? 



• Brief history of issues and/or concerns. 

Risk Summary: 

• Summarize the risk associated with the topic. 

• What is the SR&QA interest in this topic? 

• How will the requirements be verified e.g., test, analysis, similarity, simulation, etc.? 

• Are there alternative requirements? i.e., are we limiting to one design solution? If so, is 
that best or acceptable from an SR&QA perspective? 

• Identify and explain applicable options for this topic. 

• What is not being presented or brought forward for discussion? (Potential risk or 
minority opinions?) 

• Provide explanation and/or justification for all “YES” answers as a minimum from the 
attached SR&QA checklist. 

Recommendation Rationale: 

• Provide justification for the S&MA recommendation. 

• What analysis has S&MA performed (risk analysis or trade studies)? 

• What have we assured/verified (e.g. failure history, requirements, and references)? 
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Table 1 — Sample Verification Requirements Traceability Matrix 



Table 2 — Author’s Requirement’s Assessment Process 























Waivers 


Waivers within the context of this paper include all exceptions to a requirement to comprise deviations, 
variances, exemptions, non-compliances and the like. Waivers imply a risk change based on a pre-agreed 
requirement not being met along with an attached assessment to the waiver justifying the management 
decision to grant the waiver. A misleading belief is that a risk is always increased when a requirement is 
waived. This belief is further convoluted by the fact that a residual risk is usually present even with full 
compliance to the requirement. Typically a set of requirements in a requirements document is signed by a 
manager. From a risk management point of view, this manager’s signature means that the manager 
accepted the residual risk associated with a system or process when in full compliance with the 
requirements document. Unfortunately, each of the requirements within the requirements document rarely, 
if ever, are analyzed for the elements (technical basis, verifiability, and residual risk) listed in section above 
to establish a baseline risk. Therefore, typically the first time a requirement is analyzed and risk noted is 
when a waiver is requested. Then the speculated change in risk is compared with the new risk associated 
with waived requirement. Normally the waived requirement is not simply ignored but many 
countermeasures are established and implemented to control the risk associated with the waived 
requirement. 

An example of a safety variance process is one used by NASA’s Kennedy Space Center, KDP-KSC-P- 
3614, at Figure 1. The waiver form associated with this process is at Figure 2. The very process for 
generating a waiver is a microcosm of a risk management process from a safety point of view. Options are 
identified (Block 15), hazard controls identified (Blocks 16-17), risk assessed (Blocks 18-21), Opportunity 
for dissent (Block 23), and residual risk acceptance (Blocks 26 and 28). Historically, the Department of the 
Army Safety Center established its safety risk management process using a waiver format as its outline in 
1984 - a process still in place today. 


Source Selection Board Process 


The safety engineer contributes through the technical panel or Technical Evaluation Panel (TEP). The TEP 
evaluates the individual proposals, makes recommendations to the chairperson regarding clarification and 
deficiencies and assist the contracting officer during negotiations and discussions. The safety engineer is 
expected to score the safety requirements for each of the contract proposals in accordance with procedures 
established in the Request for Proposal (RFP). Engage the scoring process assuming the non-winners will 
file an unfairness compliant (i.e. protest). Therefore, insure your scoring criteria are fair, objective with all 
results well documented and defendable. A cardinal rule when evaluating technical proposals is that 
evaluation factors and significant subfactors and relative weights as stated in the RFP must be strictly 
adhered to - and not added to or varied from - in conducting the evaluation process. Do not presume the 
meaning of any part of a proposal that is not clear on its own terms and do not seek additional clarification 
from offerors on your own. A narrative justification accompanies each of your scores in order to not 
confuse the scoring of several proposals which you may have to defend weeks after you complete your 
scoring process during debriefings to unsuccessful offerors. Dissenting opinion is useful in scoring 
package when consensus of panel members can not be reached. Note: All documents created in the source 
board process may be released if formal litigation is pursued by any of the offerors. 

Bidding or costing the requirement . 

Contractors focus on requirements that impact schedule or budget. Examples of attention getting 
requirements may be a deliverable report or a design feature. During the source board process, the safety 
engineer should recruit a colleague and both should bid the set of safety requirements as if they were the 
contractor bidding on the RFP. Comparing both bids and when the variance between both individuals 
exceeds a predetermined amount, implication is that the requirement needs rework in order to be biddable 
by a contractor. A checklist of things not to do provided below may help in requirement generation. 



• Performance specified at the subsystem or component level when it could be more appropriately 
specified at a higher level; e.g., the reliability of the system or vehicle should be specified instead 
of specific components within the system. 

• Requirements not measurable or verifiable. 

• Statements constraining the solution to a single solution; e.g., "shall be fabricated from composite 
material." 

• Orphan requirements; i.e., requirement statements that are not traceable to a specific performance 
or verification requirement statement in the specification. 

• Requirement statements not appropriate for an effort in this phase of development or production. 

• Specifications relying solely on directives to define performance, not the mission requirements. 

• Citing standards and processes when performance standards can be developed. 

• Citing of mandatory standards without justification. 

• Requirements that are vague (e.g., "in accordance with commercial practices" in lieu of citing a 
commercial standard). 

Summary 

• A risk assessment process and a waiver process are based on similar or identical logic. 

• Full documentation of requirement rationale including any dissent is useful to those considering 
use of the requirement in future programs. 

• Requirements that can not be verified often result in troublesome problems. 
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Safety Variance Process 

(Note 1) 


Initiating Organization 


KDP-KSC-P-3CV4 
Rev Basic 

Objectives 

-To ensure integrity and control of the safety variance process 
-To ensure appropriate NASA-KSC- Safety and Mission Assurance 
(S&MA) involvement 

-To ensure appropriate nsk management and mitigation 
-To ensure proper nsk acceptance 


S&MA Integra ti on Division 
(Note 6) 



Approval: 

deputy Director. Kennedy Space Center 
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Figure 1 — Kennedy Space Center Variance Process 





KDP-KSC-F-3614 
Rev. BASIC 


KSC SAFETY VARIANCE REQUEST 


1 . Date of Request 2. Duration (Not to Exceed 1 Year) 
From To 


NASA Control Number 
KSC- 


3. Variance Type (Circle One) 
Deviation Waiver 


4. Requesting Organization (Enter Company Name) 


6. Document and Section (Unmet Requirement) 


8. Specify Mission Number 


9, Specify Mission/Project Name 


11. Will this activity expose NASA Personnel to 
hazardous conditions? If YES, contact AFGE 
Local 513. I I Y’es flNo 


13. Specify Procedure 


5. Location of Variance 


7. NASA Program (Select One) 

0 Shuttle □ Payloads □ EL V □ SE&T 
Institutional LJ Space Station LJ Other 


10. Safety Program (Select One) 

_ Explosives, Propellants & Pyrotechnics 
_J Lifting Devices & Equipment 
^ Lightning & Grounding 
_ Pressure Vessels 
N/A 


14. What is the specific requirements) which cannot be met (including document and section reference)? 


15. What is the rationale for not meeting the requirements), what other options were considered, and what was 
the rationale used to disposition'discard these options? 


1 6. Have any design features or procedural controls been eliminated or compromised which would affect the 
safe operation of the system/operation? 


17. What additional measures or controls have been taken to minimize risk to personnel, facilities or flight 
hardware, thus ensuring a safe operation in lieu of the requirement? 


1 8. How has the number of people exposed to the potential hazard been minimized? 


Figure 2 — Kennedy Space Center Variance Request Form 




















KDP-KSC-F-36 1 4 
Rev. BASIC 


KSC SAFETY VARIANCE REQUEST 


1 9. How has the amount of hardware exposed to the hazard been minimized? 


NASA Control Number 
KSC- 


20. What are the risks associated with failure to meet the requirements)? What are the risks associated with 
not approving this variance (i.e. 5 is there an increased risk if the requirement must be met)? 


2 1 . What is the likelihood of occurrence of a mishap with the identified controls in-place, and what are the 
consequences should the controls fail or a mishap occur? 


22. What is the plan for ensuring future compliance or partial compliance, thereby eliminating the need for 
future variances? 


23. Comments and/or Rationale for Disapproval: 


ORGANIZATION 


24. Initiator 


Approval Level (Circle One) 


System Engineer Approval Yes No N/A 


Safety Professional Approval Yes No N/A 


Approval Yes No N/A 


Approval Yes No N/A 


Approval Yes No N/A 


SIGNATURE/DATE MAIL CODE PHONE 


S&MA Mgr 


Other (Optional) 


Other (Optional) 


25. NASA/KSC 


System Engineer 


Safety Program Me 


S&MADiv Chief 


Other (Optional) 


26. Program Director 


27. Director of S&Mj 


28 Center Director 


Concurrence 

Yes 

No 

N/A 

Concurrence 

Yes 

No 

N/A 

Concurrence 

Yes 

No 

N/A 

Concurrence 

Yes 

No 

N/A 

Concurrence 

Yes 

No 

N/A 

Acceptance 

Yes 

No 

N/A 

Concurrence 

Yes 

No 

N/A 

Acceptance 

Yes 

No 

N/A 










































